1. Field of the Invention
The present invention relates to a method, system, and computer program product for file plan import and sync over multiple systems.
2. Description of the Related Art
Enterprise content management systems facilitate managing a variety of information/content (documents) and processes that use such information during the course of enterprise operations. Documents, as used herein, refer to any identifiable logical/physical units of information, including content and transactions generated by the enterprise. A document may comprise an electronic file, object, program, database, image, email, message, etc. or a physical item, such as a paper, file, cassette recording, model, etc. Documents stored in the content management system may not initially be managed as part of a records management system until they go through a “declaration” procedure that creates a corresponding record information object (RIO) for the document. Each RIO may include metadata and a reference to the declared document. The metadata describes/characterizes the declared document. The reference is, for example, a location of the document maintained in an electronic file system or database maintained in a computer-readable media. Alternatively, in the case of a physical document, the reference specifies a physical document location (e.g., a box number, a file cabinet, etc.) where the document is located. Once declared as a record, a document is managed/accessed via the content management system and access to the declared document takes place via the content management system.
Other techniques may not use the RIO/reference model and may instead directly attach record information or metadata to the document or object itself or use other means to track and/or manage records.
The scope of content represented by RIOs is not limited to any particular type of document form or location. A variety of document types are potentially referenced by the RIOs of the records manager. Such document types include, by way of example: formal documents such as permits, invoices, tax records, patents, contracts, claims, manuals etc; informal documents such as email messages (and attachments), text messages, meeting notes, etc.; multimedia content such as audio, video files; and physical containers such as file boxes, cabinets, folders, etc. The documents referenced by the RIOs are potentially stored in a variety of forms and locations. For example, electronic documents including images, text files, forms, etc. are potentially stored in file systems and databases. Physical documents referenced by RIOs are potentially stored in cabinets, boxes, file folders, etc.
After declaring a document, the associated RIO is maintained in an electronic object storage facility referred to as a “file plan object store” including one or more “file plans”. In certain cases, file plans for documents may be maintained without a file plan object store. Each file plan comprises an outline/definition for record management based upon a hierarchically arranged set of categories (classes/subclasses) and containers for classifying/organizing/maintaining the RIOs and their associated declared documents. A known file plan arrangement for storing records includes the following containers: categories/sub-categories, record folders, and record volumes. In addition to defining a taxonomy of document types declared within the system, the file plan supports specifying management rules for RIOs placed within particular document categories and sub-categories. Such rules include user role-based access/permissions to RIOs and their associated documents, and defining disposition schedules specifying when particular disposition actions (e.g., transfer, review, destroy, archive, etc.) are to be taken with respect to documents declared under the category. Thus, the known file plan structure can be visualized as a hierarchical tree structure where nodes potentially specify distinct containers (e.g., category or container of categories). Each category within the file plan potentially specifies a set of properties and lifetime document management rules for associated document records.
Also, as an example, a file plan may consist of categories, folders, volumes, schedules, events, actions, workflows, cycles, etc.
A file plan may initially be developed at a development system, and then modified in a production system. Conventional techniques do not easily manage the file plan development and deployment process. With conventional techniques, several manual steps are usually involved. In current systems, export and import are usually separate steps. For example, in one step, an administrator runs a process on SystemA to export the file plan to a file. In the next step, an administrator runs a process on SystemB to import the file plan from the file into SystemB.
There is a need in the art for improved techniques for file plan import and sync over multiple systems.